home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group00b.txt / 000015_icon-group-sender _Mon Jul 10 08:02:48 2000.msg < prev    next >
Internet Message Format  |  2001-01-03  |  5KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA20447
  4.     for icon-group-addresses; Mon, 10 Jul 2000 08:02:40 -0700 (MST)
  5. Message-Id: <200007101502.IAA20447@baskerville.CS.Arizona.EDU>
  6. Date: Mon, 10 Jul 2000 16:51:56 +1200 (NZST)
  7. From: "Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
  8. To: gep2@terabites.com, icon-group@optima.CS.Arizona.EDU
  9. Subject: Re: Error messages
  10. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  11. Status: RO
  12. Content-Length: 4073
  13.  
  14. I wrote:
  15.     > I just _have_ to ask:  WHICH hassle?
  16. Gordon Peterson wrote:
  17.     I've written a **lot** of such stuff (admittedly in
  18.     SNOBOL/SPITBOL rather than Icon, but the principle is certainly
  19.     similar).  I don't think you have anything like the same capabilities
  20.     and ease of programming in Prolog that you have in S*BOL or in Icon.
  21.     
  22. I've been a SNOBOL user off and on since the mid-70s.
  23. I still use SNOBOL on UNIX, quite happily.
  24. One of the first things I did when I met Prolog was to figure out
  25. the equivalents in Prolog.  It used to surprise people when I pointed
  26. out that there was prior art for "!" in SNOBOL's FENCE.
  27.  
  28. The thing is that SNOBOL gives you *almost* but not quite the same
  29. power and convenience for parsing text as Prolog does, but there it stops.
  30. As an anthropologist pointed out to me in the mid-70s when I was trying to
  31. persaude everyone to use SNOBOL, "if it can't parse anything but strings,
  32. what's the big deal?"  Icon is a step backwards for parsing strings, but a
  33. big step forward for matching other kinds of data structures.  But even
  34. Icon has a long way to go to match the ease of programming in Prolog.
  35.  
  36.     Now it could be that you don't program in S*BOL or Icon the way I do, or that 
  37.     maybe you'd just rather do it (for whatever perverse reason) in Prolog.  Hey, 
  38.     whatever floats your own personal boat...
  39.     
  40. You don't have to be perverse to prefer Prolog.
  41. You just have to like being able to use labelled trees as data structures
  42. and the ease of pattern matching on them.
  43.  
  44. Seriously, the two big differences between Icon and Prolog here are
  45.  - Icon has assignment statements, Prolog doesn't.
  46.  - Icon looks a lot like C, Prolog doesn't.
  47.  
  48.     It's the other areas surrounding the project where the real
  49.     benefits show up.
  50.  
  51. Which areas, exactly?  That's really what this thread is about.
  52. Generating binary output as such isn't a problem in Icon _or_ Prolog.
  53. I've identified "figuring out what the output structure is" as a problem.
  54.  
  55.     The script compiler I wrote for the French Social
  56.     Security Administration was written in a day and a half, and produced
  57.     the most beautifully complete and detailed listings (cross references,
  58.     formatted symbol tables, error summaries, and even a listing table of
  59.     contents) you ever saw.  It would have taken at least six months to
  60.     write the same thing in C/C++, and maybe not a whole lot less to have
  61.     written it in Prolog.
  62.  
  63. Can you give any *reason* why it would have been hard in Prolog?
  64.  
  65.     > Writing the output is the tricky part.  The real hassle is finding out what 
  66.     the wretched output is supposed to look like.
  67.     
  68.     I claim that THAT is only part of the hassle too.
  69.  
  70. My point is that it is a *major* hassle, given the state of the documentation,
  71. and that it is a *language-independent* hassle.
  72.  
  73.     But hey, as I said, I've got 
  74.     better things to do than to go through a detailed point-by-point argument with 
  75.     you if you really want to do it in Prolog
  76.  
  77. This is an Icon mailing list, and "what language features help or hinder
  78. for this kind of task" is *exactly* what this thread is about.
  79. Surely you have better things to do than hurling around unjustified
  80. (and unjustifiable) insults against other programming languages.
  81. Shouldn't explaining *how* Icon helped you so much be one of them?
  82.  
  83.     > For UNIX (maybe Windows too; I've never used Cygwin) anyone wanting to write
  84.     a new kind of assembler would be mad not to re-use as much of the GNU binutils
  85.     as practical.  By all means put a smart new front end on an assembler, but
  86.     let someone else deal with the *real* hassle.
  87.     
  88.     Well, I guess it depends on whether you want an assembler that works like 
  89.     everyone else's or not.  (Buf if you're happy with existing ones, why write a 
  90.     new one at all?)
  91.     
  92. This is a rather strange comment.  The original question came from someone
  93. who wanted to do a new kind of analysis of the input.  Nothing was said
  94. about wanting to produce incompatible binary object files.  If it is to be
  95. useful, presumably that person *does* want an assembler whose *output*
  96. conforms to the same interface requirements as everyone else's.
  97.  
  98.